Dúvida no Preenchimento dos campos PREFNO / CHECOD em NFS-e de SP

Olá Pessoal,
Estou a procura de informações sobre a solução para nota fiscal eletronica de serviços da prefeitura de São Paulo, pesquisando no forum pouco encontrei sobre a nota 981687 - NFe: For Services in Muncipio Sao Paulo.
A SAP disponibilizou os dois campos PREFNO / CHECOD para o numero da nota fiscal e código de verificação gerados pela prefeitura (uma vez que o SAP deve gerar o número da RPS), além de um report para geração do arquivo TXT e envio manual.
Minha dúvida é a seguinte:
1) Após enviar o arquivo para a prefeitura, são convertias as RPS em Notas Fiscais Eletronicas. Como armazenar as informações nos campos standards mencionados ? Existe um outro report que le o arquivo de retorno da prefeitura ?
Outra dúvida está na procura de uma sugestão, onde o RPS pode ter até 12 posições e o NFNUM do SAP apenas 6. Vcs estão utilizando outro campo Z para compor o numero maior ? Ou como esta fazendo quando o RPS atingir 999.999 ? Pensei en usar o NFENUM, mas teria o mesmo problema quando atingir o limite de 9 posições (999.999.999).
Muito obrigado pela atenção e ajuda.

A_cristovao ,
Vamos ver se posso lhe ajudar em algo:
1) Após enviar o arquivo para a prefeitura, são convertias as RPS em Notas Fiscais Eletronicas. Como armazenar as informações nos campos standards mencionados ? Existe um outro report que le o arquivo de retorno da prefeitura ?
Resposta: Em alguns projetos que passei, consultei os abaps e sempre foi desenvolvido um programa Z para ler este arquivo e fazer um BDC na J1B2N, porem sua categoria de nota não dever ser eletrônica, aqueles dois campos flag no cabeçalho NF eletronica e NF servico, apenas o último(serviço) marcado para o BDC entrar e conseguir mapear o campo com o NFSe e cod verificador.
2) Outra dúvida está na procura de uma sugestão, onde o RPS pode ter até 12 posições e o NFNUM do SAP apenas 6. Vcs estão utilizando outro campo Z para compor o numero maior ? Ou como esta fazendo quando o RPS atingir 999.999 ? Pensei en usar o NFENUM, mas teria o mesmo problema quando atingir o limite de 9 posições (999.999.999).
Resposta: Esse estamos usando o NFNUM mesmo, não chegamos a nos preocupar com isso devido ser um volume baixo de NFS, talvez um chamado no componente XX-CSC-BR-NFE lhe ajude.
Abraço,
Bruno Lima

Similar Messages

Preenchimento dos campos cEAN e cEANTrib no XML da NFE

Boa tarde,
   A partir de 1º de julho de 2011, segundo o Ajuste SINIEF n. 16, de 16/12/2010, será obrigatório O preenchimento dos campos cEAN e cEANTrib com o GTIN (Numeração Global de Item Comercial) caso ele exista. A diferença entre os campos é que no campo cEAN será informado o GTIN do produto que irá constar os dados referentes ao fabricante, distribuidor , etc. Já no campo cEANTrib será informado o GTIN da unidade tributável, referente aos impostos atribuidos ao produto.
   Onde faço o preenchimento destes campos para que apareçam no XML da NFe?
   Utilizo o ECC 5.0 e GRC Nfe 1.0 (SAPK-10015INSLLNFE).
   Exemplo do XLM gerado atualmente:
<cEAN />
<cEANTrib />
   Exemplo do código cEAN e cEANTrib: 07896534703010
Att. Ronaldo
Moinho Sul Mineiro

Bom dia Pessoal,
É um erro localizado na Sefaz MG por favor abram tickets no 0800 da Sefaz MG para correção do problema.
Atenciosamente, Fernando Da Rós
PS: Evitem postar em threads já respondidas, isso confunde a solução válida. Além de evitar a classificação da solução por pontos. Podem "gastar" criando novas threads...
Edited by: Fernando Ros on Oct 20, 2011 12:50 AM

Venda Intercompany – Preenchimento dos campos xPed e nItemPed

Boa tarde Pessoal,
Andei pesquisando mas sem sucesso por isto venho pedir ajuda.
http://scn.sap.com/thread/3263202
http://scn.sap.com/thread/3274014
https://scn.sap.com/thread/1838307
No ECC:
O cenário standard de venda intercompany é muito similar ao de transferência entre plantas da mesma empresa.
Em ambos os cenários, a remessa de SD é criada a partir do pedido de compras (VL10D).
Não existe ordem de venda (OV) !
No NFE10 inbound (automação)
- a transferência é tratada como STOCKTRF.
- a venda intercompany é tratada como NORMPRCH. Neste cenário, para não termos que fazer manualmente a etapa "atribuir itens de pedido” precisamos que o XML seja preenchido corretamente.
Por isto pergunto:
Que campos devemos preencher no ECC para que os campos <xPed> e <nItemPed> sejam preenchidos no XML ?
PS1: Testei com B2B ativo configurado com X (PI) e com D (database) => Sem sucesso.
PS2: Em cenários de venda com OV os campos são preenchidos corretamente
PS3: Ambiente ECC604 SP12 + GRC10 SP14
Desde já obrigado.
Rafael

Oi Fernando,
Estamos aguardando resposta do chamado, qualquer novidade posto aqui.
Não entendi sua frase:
A todos os projetos que estão passaram pelo layout 2.0 sugeri que incluíssem este tópico, mas neste momento concordo que fica bem difícil de garantir ele com a obrigação chegando.
Poderia explica-la melhor ? Esse tópico que se refereu é o Decouple ? Qual seria essa obrigação?
Sim, fizemos os testes enviando uma nota em memória e não são preenchidos os campos, e depois em uma nota retransmitida, são enviadas as tags, sem nenhuma outra modificação via BADI. Essa é a diferença entre os XMLs.
Os campos não são obrigatórios, apenas um dos nossos clientes de B2B que solicitou o preenchimento para todos os seus pedidos. Acreditava que o Standard daria esse suporte, mais entendo que apenas funciona para os locais de negocio com Decouple ativado, o que questiono pois pelo processo desenhado ainda não foi possível definir / ativar o decouple. Além que devem ser realizadas outras modificações da BADI, pois outras informações já estão buscando da memória e temos que modificar para buscar das tabelas (passar do modo mais dificil para o mais fácil da implementação, conforme vc mesmo comentou, rsss).
Obrigado pela ajuda e atenção.

Rejeição do validador do GRC dos campos IND_PRES e IND_FINAL

Bom dia,
Estou implementando o layout 3.10 da NF-e e encontrei um problema na validação dos campos IND_PRES e IND_FINAL.
O cliente possui SAP_APPL 600 SP 24.
O problema é na chamada do método FILL_HEADER da BAdI CL_NFE_PRINT: antes da chamada do método, os campos xmlh_310-ind_pres e xmlh_310-ind_final são valorizados. No entanto, após a chamada desse método, como não faço nenhuma alteração nos campos IND_PRES e IND_FINAL, as seguintes linhas de código sobrescrevem os valores da estrutura xmlh_310 com valores iniciais:
Include: LJ_1B_NFEF41
    if xmlh_badi is not initial.
      move-corresponding xmlh_badi to xmlh."#EC ENHOK
       IF xmlh-version >= gc_nfe_version_3.                "1933985
->          move-corresponding xmlh_badi to xmlh_310.       "2048213
      ENDIF.                                              "1933985
Alguns comentários:
1) Na implementação do método FILL_HEADER, a primeira coisa que eu faço é um MOVE-CORRESPONDING:
MOVE-CORRESPONDING in_xml_header TO out_header.
MOVE-CORRESPONDING in_doc TO out_header.
2) Acho muito estranho que o parâmetro de Import IN_XML_HEADER seja do tipo J1B_NF_XML_HEADER, pois nessa última estrutura não vejo os campos IND_PRES e IND_FINAL. Procurei notas relativas aos campos da J1B_NF_XML_HEADER, mas não achei nada de relevante para o meu problema.
3) Antes da aplicação da nota 2048213 existia um check para verificar se os valores eram iniciais antes de sobrescrevê-los com o move-corresponding...
4) Na chamada do método FILL_HEADER, a estrutura xmlh é passada, mas a estrutura xmlh_310 não. Então eu não tenho acesso aos campos xmlh_310-IND_PRES e xml_310-IND_FINAL no método FILL_HEADER.
Agradeço muito se puderem ajudar a resolver esse problema.
Obrigado!
Luis

Olá, Luis.
Acredito que seja um pouco tarde para responder, pois provavelmente você já resolveu seu problema.
Os campos IND_PRES e IND_FINAL estão na estrutura in_doc.
O que fizemos foi incluir na BADI FILL_HEADER os comandos de MOVE na seguinte ordem:
MOVE-CORRESPONDING in_doc TO out_header.
MOVE-CORRESPONDING in_xml_header TO out_header.
Com isso, os campos acima foram preenchidos corretamente na BADI, e nenhuma outra ação foi necessária.
Por favor me avise caso ainda ocorra o problema.
Abraço e boa sorte
Rodrigo Ferreira

Búsqueda formateada - actualizada con dos campos

Hola estimados!
¿Alguien sabe si se puede actualizar una búsqueda formateada si se modifica cualquiera de dos campos?
Gracias!!!

algo mas o menos asi es lo que yo uso, para modificar lascuentas de ingresos en venta y costo dentro de las ordenes de venta.
al darle shift+f2 lo que hago es seleccionarlo del query manager( la consulta), y luego pongo la opcion de cambiar actualizacion automatica con la opcion de la lista al salir de columna modificada, selecciono almacen , que es la que youtilizo como base para el cambio de mi cuenta y en mi query, tomo en cuanta el dato de la cabecera SERIE.
SELECT CASE WHEN ($[$8.0.0]>=1 AND $[$8.0.0]<=999999) THEN
'550000001'
WHEN ($[$8.0.0]>=1000000 AND $[$8.0.0]<=1999999) THEN
'550000002'
END
FROM OITM T1
WHERE T1.ITEMCODE=$[$38.1.0]
Te puede ayudar !

Atualização da Vida útil expirada dos imobilizados mensalmente

Boa tarde,
A Vida útil expirada dos imobilizados esta sendo atualizada somente no final de cada ano.
Eu preciso que seja mensal.
Alguém sabe como fazer isso ?
Grata,
Cleide.

Olá Cleide.
Você conseguiu resposta para essa sua antiga questão?
Estou passando pelo mesmo problema.
Muito Obrigado
Boa tarde,
A Vida útil expirada dos imobilizados esta sendo atualizada somente no final de cada ano.
Eu preciso que seja mensal.
Alguém sabe como fazer isso ?
Grata,
Cleide.

Campos cEAN e cEANTrib no XML da NFE (NT 2011/004)

Bom dia,
A partir de 1º de julho de 2011, é obrigatório o preenchimento dos campos cEAN e cEANTrib com o GTIN (Numeração Global de Item Comercial) caso ele exista.
A diferença entre os campos é que no campo cEAN será informado o GTIN do produto que irá constar os dados referentes ao fabricante, distribuidor , etc.
Já no campo cEANTrib será informado o GTIN da unidade tributável, referente aos impostos atribuidos ao produto.
Sabemos que o preenchimento do cEAN é realizado através do campo standard no cadastro do material, e o cEANTrib é o mesmo número, e este cenário eu consigo tratar na BADI preenchendo abos os campos com os mesmos valores.
Porém temos uma particularidade que é a seguinte:
Tem um determinado cliente que me compra caixas com 24 unidades de óleo, e neste caso, o cEAN e o cEANTrib serão diferentes.
Ex.:
cEAN: 12345 (CDA)
cEANTrib: 123456 (CX)
No cenário normal, envio preencho as tags cEAN e cEANTrib com o código do cEAN (12345) que está cadastrado no campo específico do cadastro do material (MARA-EAN11).
No cenário "especial", o GTIN tributado é diferente, preciso enviar na tag do cEAN o GTIN da CX (123456) e na tag do cEANTrib envio o GTIN do CDA (12345). Ambos os valores estão cadastrados nas informações adicionais do cadastro do material na aba de "EANs adicionais" conforme abaixo:
UM alt     Texto un.     Código EAN/UPC     Ctg.EAN
CDA     cada     7898357410015     HE
CX     caixa     17898357410012     IC
Como trato isso? Pois na BADI não tenho o campo do cEAN para tratar...
Obrigado,
Mateus.

Oi Matheus.
Você pode fazer habilitar este campo na BADI fazendo um append Z na estrutura IF_EX_CL_NFE_PRINT~FILL_ITEM. Fizemos isso para habilitar outros campos como por exemplo o E1_FONE no cabeçalho da NF-e.
Abraço
Eduardo Chagas

NFe - Obrigatoriedade da chave de acesso nas NFs de entrada.

Olá
Verificando no Site do SPED temos a nova alteração abaixo para Janeiro/2012
http://www1.receita.fazenda.gov.br/noticias/2011/setembro/noticia-23092011.htm
"Disponibilizada a versão 2.0.6 do Guia Prático da EFD (Art. 1º do Ato COTEPE ICMS 41/11).
Obs.: Foi regerada a versão do Guia Prático da EFD (2.0.6A) apenas para correção do documento, sem qualquer outra modificação. A partir de janeiro de 2012, o número da Chave de Acesso da NF-e e CT-e, nas operações de entradas, passa a ser informação obrigatória."
Para os casos de NFes de MM, não temos problema, pois todas as entradas já são preenchidas manualmente, mas temos um problema nas entradas via SD onde não existe um campo para o preenchimento da chave de acesso durante o processo de uma ordem de devolução por exemplo.
Na geração da entrada via SD, os campos de número aleatório e dígito verificador não são preenchidos, deixando a chave de acesso incompleta.
Gostaria de saber se existe alguma forma de fazer o preenchimento destes dois campos durante o processo de forma a garantir que sempre a chave de acesso seja criada corretamente em uma geração de NF de entrada SD via transação VF01.
att,
Denis C. Santos

Oi Denis,
creio que hoje o procedimento requer que o usuário vá na J1B2N para preencher essas informacoes, depois de criar a fatura.
Alternativamente, vc poderia abrir um popup na exit da VF01 para preenchimento dos campos quando fosse devolução.
Abs,
Henrique.

Nota fiscal rejeitada por campos 'pMVAST, pRedBCST, vBCST' vazios no processo de transferência de crédito de ICMS

Pessoal, bom dia!
Vejam se alguém já passou por algo parecido em algum projeto...
Estou com uma demanda pra alterar alguns parametros do processo de transferência de crédito de ICMS, que são:
1- A quantidade deverá ser preenchida com “0”.
2- O valor unitário deve ser “0”.
3- O campo de unidade de medida “Vazio”
4- A NCM não deverá ser vazia, mas ser preenchida com “00”.
5- O CST deverá ser “090”.
A solução para os pontos 1, 2 e 3 foi criar um enhancement na função J_1B_NFE_PROCESS_OUTBOUND relacionada a J1B1N para alterar os valores digitados pelo usuário assim que a nota estiver sendo criada. Para o ponto 4, a solução foi criar um NCM "00" para utilização do usuário.
E, no ponto 5, a solução foi orientar o usuário a optar pela origem do material "0" e optar pelo direito fiscal IC9 (Outros) que atribuirá a tributação 90, formando assim o 090 esperado.
O problema é:
Ao dar saída na nota fiscal pela J1B3N, ela está sendo rejeitada pelo fato dos campos 'pMVAST (Percentual da margem de valor Adicionado do ICMS ST), pRedBCST (Percentual da Redução de BC do ICMS ST), vBCST' (Valor da BC do ICMS ST) não estarem sendo preenchidos.
Sendo assim, como posso resolver esse ponto?
Em anexo está a tela do preenchimento da Writer com os devidos parametros e impostos, e está também o IDOC que foi gerado com os campos em branco.
Desde já agradeço a atenção.

Allan, boa tarde!
Obrigado pela sua resposta, mas, conforme venho conversando com o fiscal resposável do projeto, o cenário é esse mesmo.
Seguem abaixo e em anexo as regras Fiscais para emissão da nota de transferência de crédito de ICMS:
Orientação de Preenchimento NF-e:
Transferência de crédito
A nota fiscal eletrônica (NF-e) também será emitida nas hipóteses de transferências de crédito acumulado de ICMS em razão de exportação, diferimento ou redução da base de cálculo.
De acordo com a legislação, há regras a serem observadas para a emissão da NF-e referente a essa transferência de crédito. Resumidamente, alguns procedimentos comuns que poderão ser seguidos.
Para emitir a NF-e, é necessário informar nos campos próprios:
1. Como destinatário, o nome, o endereço e os números de inscrição estadual e no Cadastro Nacional de Pessoa Jurídica (CNPJ) do contribuinte ao qual se está efetuando a transferência;
2. Nas Informações Complementares do quadro “Dados Adicionais”, a expressão “Transferência de crédito acumulado de ICMS, nos termos (indicar o base legal da transferência)” e o valor, por extenso, do crédito transferido. No aplicativo gratuito emissor da NF-e, essa informação constará no campo “Informações Complementares de interesse do contribuinte” da aba “Informações Adicionais”;
3. No local destinado ao valor da operação do quadro “Cálculo do Imposto”, o valor do crédito acumulado transferido (no aplicativo gratuito de NF-e, esse valor será informado no Valor Total bruto). Nos demais campos, preencher com “0” (zero) para todos locais numéricos e obrigatórios nos quais não consta orientação específica - apenas um dígito “0” em cada, pois a NF-e trabalha com campo preenchido;
4. Como natureza da operação: “Transferência de Crédito Acumulado de ICMS”;
5. No campo “Finalidade de emissão” informar “NF-e de Ajuste”;
6. Os CFOP e CST serão os códigos 5.601/5.602 e 090, respectivamente;
7. A Nomenclatura Comum do MERCOSUL (NCM) será informada a expressão numérica “00”;
8. A “Descrição do Produto” será informada a expressão “Transferência de Crédito Acumulado de ICMS”;
9. A situação tributária do PIS e da COFINS será “Operação sem incidência da Contribuição; e
10. A “Modalidade do frete” indicar “Sem frete”.
8. Código de Situação Tributária – informar “90”. Página 168 do Manual de Integração.
Na Nota Técnica 2013/005, ainda é informado que os campos 'pMVAST, pRedBCST e vBCST' devem ser carregados no XML, e por se tratar de tranferência de crédito, os valores devem ser “zerados”.
Aplicando o imposto ICS3, consigo inserir zeros nos campos indicados acima. O problema é que a NF é rejeitada novamente só que com erro no campo vBCSTRet (Valor da BC do ICMS ST retido), pois ao zerar os campos acima acabo obrigatoriamente atribuindo zero ao campo vBCSTRet, fato que não deve ocorrer.

Campo de usuário em tabela de usuário não respeita o tamanho definido

Criei uma tabela de usuário e dentro dela criei 10 campos alfanuméricos com tamanho de 10 posições. Ao executar a procedure SP_HELP no SQL Server para verificar o tamanho dos campos na estrutura da tabela verifiquei que o tamanho foi definido como -1, ou seja, o tamanho do campo não foi corretamente informado pelo B1 na criação da tabela e o SQL Server 2005 acabou por assumir como padrão o tamanho máximo de 4096 bytes.
Se olharmos apenas para a definição da tabela e dos campos no B1 os valores são apresentados corretamente, mas não correspondem aos valores definidos nos metadados do banco. Isso é extremamente problemático pois derruba violentamente a performance das consultas nas tabelas de usuário.
Existe algum workaround que a gente pode utilizar para resolver este problema?
Testamos a criação de tabelas e campos de usuários na versão 2005B, rodando no SQL Server 2005 com as PLs 40, 41 e 42 e nessas três configurações o problema ocorreu sempre da mesma forma, como descrito acima.
Sei que podemos forçar a correção da estrutura de dados das tabelas na mão, pelo comando ALTER TABLE do SQL Server, mas isso será apontado pelo Early Watch? Corremos o risco de perder a garantia do produto?
Qualquer informação que ajudar a solucionar este problema será muito bem aceita.
[]'s
Edited by: Rui Pereira on Nov 7, 2008 9:27 AM

Oi Vitor,
O problema ainda não foi resolvido. Abrimos um chamado na SAP pois entendemos que este comportamento do SBO não é o correto uma vez que ao definir campos alfanuméricos com o maior tamanho possível, as estruturas (metadados) acabam ficando gigantes e isso joga a performance dos add-ons e consultas formatadas pra baixo.
Você pode reproduzir o problema criando UDFs em tabelas standard ou em UDTs pelo próprio B1. Não precisa criar os campos pelo SDK para que o problema ocorra não. Basta definir o campo do tipo Alfanumérico que, ao executar a SP_HELP no SQL Server você verá a estrutura do seu campo mais ou menos assim:
CAMPO NVARCHAR(-1)
Na documentação do SQL Server é explicado que o -1 representa a capacidade máxima de armazenamento do campo.
Este problema só acontece no SQL Server 2005. No SQL Server 2000 o B1 se comporta bem.
Edited by: Gabriel Izar on Oct 8, 2008 3:31 PM

Validação XML 3.10 (campo série)

Boa tarde pessoal.
Estou com um problema aqui um pouco estranho.
Estamos fazendo a configuração do XML 3.10, e agora está acontecendo um erro.
Durante a chamada da função /XNFE/OUTNFE_CREATE, que cria a nota de saída no GRC, é chamada a função /XNFE/OUTNFE_VALIDATION. Essa função faz a validação dos campos da nf-e de acordo com as regras existentes na tabela /XNFE/XMLVALID.
Quando essa função vai validar o campo SERIE, o mesmo retorna erro na validação.
A expressão regular da expressão é:
0|[1-9]{1}[0-9]{0,2}
O valor da Série é "001".
Teoricamente essa expressão regular permite utilizar esse valor, pois ela permiti ou o literal "0" apenas, ou valores com pelo menos 1 dígito obrigatório de 1 à 9, com até dois dígitos (não obrigatórios) de 0 à 9.
Essa expressão deveria permitir, "1 ", "001", " 01", " 1", etc.
Eu testei a expressão em sites da internet com esta regex, e funcionou perfeitamente.
Testei alterar a expressão (teste em programa Z) para 0|[0-9]{1}[0-9]{0,2}, e ai sim a expressão funcionou. Parece que o ABAP está considerando que é obrigatório que o primeiro campo da série seja diferente de 0.
Att,
Matheus Goulart

Ola Matheus ,
   Tivemos o mesmo problema em um cliente, se você desativar o validador do GRC vai e enviar o xml request (versão 3.10) para SEFAZ de origem você vai ter um erro de falha do xml.
   Verifique no xml da versão 2.0 o valor da tag <serie>. Mesmo enviando para o GRC a serie "001" o valor no xml ficava como <SERIE>1</SERIE>.
   Em resumo: Fizemos fizemos um ajuste na BADI CL_NFE_PRINT no metodo HEADER e retiramos os "zeros a esquerda" da série da nota fiscal e não tivemos mais problemas.
BR
Allan Pizaia

Retornar Valor de Campo de Usuário C#

Olá a todos.
Estou com um problema para receber um valor vindo de um campo de usuário, quando estou fazendo uma interface UI, em C#.
O nome do meu campo é U_NCliente. Estou utilizando o seguinte codigo:
valor = ((SAPbouiCOM.UserDataSource)oForm.Items.Item("U_NCliente").Specific).ToString();
Para todos os outros campos do form, utilizei o mesmo código, apenas trocando o número do item, porém quando tento retornar esse valor de um campo de usuário, recebo o seguinte erro:
Item - Invalid item . Form Unique Id: 'F_11', Item Unique Id: 'U_NCliente'
Para os outros campos, do tipo EditText e ComboBox, o mesmo código funcionou corretamente.
Obrigado.

Problema resolvido.
Para receber o valor de um campo de usuário, é necessário adicionar o seguinte código para passar o id do form dos campos de usuário antes:
oForm = oApp.Forms.GetFormByTypeAndCount(-150, oApp.Forms.ActiveForm.TypeCount);
Ficando o código assim:
oForm = oApp.Forms.GetFormByTypeAndCount(-150, oApp.Forms.ActiveForm.TypeCount);
valor = ((SAPbouiCOM.EditText)oForm.Items.Item("U_NCliente").Specific).String;
Obrigado.

Select em campo váriavel do B1.

Pessoal, boa tarde,
Na tela de baixa de títulos do contas a pagar existe a coluna N.Documento, preciso pegar o valor que ela apresenta para fazer um select na tabela de entrada de notas fiscais e trazer um valor para preenchimento do campo Referência também na tela do Contas a Pagar.
Como faço o select para pegar o valor dessa coluna do item que acabou de selecionar? É possível?
O valor que o B1 me da no rodapé é:
240510
Já tentei "Select $[$426.DocNum.0]", já tentei "Select $[$426.000004432,DocNum.0] dentre outras diversas tentativas e não consegui.
Alguém saberia como proceder nessa situação?
Obrigado a todos!

Olá Ribeiro Kelin, para exemplificar fiz um teste e capturei as telas, abaixo segue:
Criei a tabela "TESTESCN"
Depois adicionei um campo a tabela
Para inserir os dados acessei a tabela em:
Deve-se usar os dados do menu "Visão" em "informações do sistema" se deseja pegar as informações em tela antes da gravação em banco de dados, conforme padrão de consultas.
Depois criei um consulta, gravei a consulta em "consultas do usuário" e apliquei no campo de usuário a consulta formatada, ao clicar na lupa busca os dados em tela.
Se a questão é consultar no banco, ao criar uma tabela o SBO coloca por padrão "@" no nome da tabela, antes da descrição definida pelo usuário, então abaixo segue o código para consulta no banco de dados.
Espero ter colaborado.
Att,
Rodrigo da Costa Feula

Nuevo recibo de salarios - Forzar impresión en dos páginas

Hola a todos,
al incluir en el recibo de salarios (PE51) los conceptos a incluir en el nuevo recibo de salarios al final del recibo, resulta que el recibo no cabe en una única pagina al imprimirlo.
¿Sabéis si existe alguna forma de introducir un salto de página al imprimir el recibo, de forma que toda la parte de devengos quede en una página y la parte correspondiente a las cotizaciones de la empresa (es decir, básicamente el formulario de muestra incluido en la nota 2142736 se imprima en una página aparte? No estamos utilizando Smartforms.
Muchas gracias,

Hola Marian Martin Martin y Josep:
En recibos formato PE51 lo de imprimir en una segunda hoja ocurre cuando las lineas/columnas del formulario superan las lineas del formato de impresión que se fija en el momento de imprimir.
Si tenéis un recibo PE51 de 75 lineas y que eliges el formato de impresión 65 lineas; las 10 ultimas lineas se imprimen en una segunda hoja.
Otra opción que tenéis; aunque tengo que decir que no recuerdo del todo como lo hice entonces; es añadir el commando NEW-PAGE via una conversión Z en el RPCEDSZ9 de tal forma que la impresión lo interprete como salto de pagina. Buscando en mis archivos en encontrado un pantallazo pero falta el detalle; pero bueno algo ayuda
De lo que recuerdo, los recibos PE51 se almacenan en un tabla interna que se llama XFORM que tiene el formato PC408. Este formato tiene dos campos; el primero LTYPE y el segundo LINDA. Aquí el juego consiste en añadir una linea con el valor "/:" en la primera y NEW-PAGE o <NEW-PAGE> (no recuerdo exactamente cual) en la segunda.
Por mi parte de momento he podido adaptar todos los recibos de los varios clientes que tengo manteniendo una hoja de impresión,,, tanto los recibos normales como los finiquitos... ; todo el mundo lo agradece; el cliente porque no tendrá que duplicar su presupuesto de hoja dyna4 para los recibos de nominas y el planeta porque somos eco-friendly. Pensadlo por si podéis afrontar el cambio manteniendo una pagina.
Antoine

Campos para Transportation-ECC

Olá pessoal,
Por favor, alguém de vocês já precisou utilizar campos como nº de RENAVAM, cor do veículo, tipo de veículo, condição do veículo, placa, contato do proprietário? Como fizeram?
Obrigado,
Renato Pereira.

Olá Renato,
Não estou certo de onde exatamente você precisa inserir estas informações, mas como você mencionou "Transportation" vou chutar rs.
Se for isto mesmo, os campos abaixo na VT01N não te atendem? Caso em seu projeto estes campos já não tenham uma função específica, você pode manter as tabelas destes campos no customizing de acordo com a sua necessidade e alterar os elementos de dados correspondentes, para que os rótulos dos campos e campos da tabela correspondam ao que você precisa.
abs.

Dúvida no Preenchimento dos campos PREFNO / CHECOD em NFS-e de SP

Similar Messages

Maybe you are looking for